Current Personal Information Management (PIM) systems and Customer Relationship Management (CRM) systems use a static data model in which business tasks are predefined during CRM system design time and are realtively fixed once the system is created. Consequently, business task data is usually organized and stored as fixed, stand-alone data structures comprising all necessary attributes of a business task as conceived at design time. The problem with fixed, stand-alone data structures is that they are inflexible and do not allow for modifications to the task structure after design time and they do not account for views for task data that are inconsistent with the predefined task model.
FIG. 2 shows a CRM data structure used in existing systems. The data structure corresponds to a generic task that is defined to contain all information necessary to perform a task, e.g., fax information, email information, customer information, and document information. This task structure makes it easy to query for a result set comprising the entire task structure as defined, i.e., querying to return all fields of the entire task based on some attribute of the task. However, on inspection of the generic task structure, several subcategories of tasks can be easily discerned, e.g., faxing, e-mailing, new customer creation, document creation, etc. Each of these subcategories of information may be thought of as separate tasks, or subtasks. Consequently, users of CRM systems often desire a view of task data in which the displayed result set is actually a subtask of the generic task, as defined by the existing task data model. Additionally, users may desire to view a subtask based on another subtask. For example, a desired view could be a result set listing all faxes to be sent out that relate to proposal documents. In this case, the user desires a view of all fax tasks having an association to a document task. While a result set can be created from the existing generic task structure through database querying, such queries are complex and resource consuming, even with the aid of category and sub-category fields used by some CRM systems to demarcate their data subsets.
In addition to viewing subtasks of a main task structure, CRM users may also desire the ability to customize an existing task or subtask. For example, a fax subtask may currently have only a set of headers that were included with the fax subtask at design time. CRM users may want to add additional headers, or include a customized fax cover. The CRM users may also want this modified fax subtask as an additional fax task definition while retaining and using the original fax task definition.
Existing fixed, stand-alone data structure models fail to address the issue of capturing new task data at runtime or creating new task views based on existing task data. One means presented in prior art systems for providing flexibility to the existing data models is to create reserve parameters and attributes in the existing data structures for future use. While this reservation strategy may allow for some future customization, it is limited by memory considerations because each allocated, but unused, parameter of an instance of a data structure is wasted memory space.
Another problem of fixed stand-alone data structures is that as the functionality of CRM systems increases and new tasks are added to each new CRM version, the existing data structures grow to be immensely large and complex, because they are designed to contain every necessary data category in a single-entity data structure. Managing such huge data structures consumes a large amount of processing capacity because the amount of parsing and formatting required to return a specific result set (or view) is commensurate with the size of the data structures.
Therefore, there is a need for an improved data model for CRM systems for storing and organizing task data in a more efficient and extensible manner than is currently offered.
The claimed method and system provides a data organization process for use in a customer relationship management (CRM) system where task data is decomposed into a set of task objects defined, in part, by a base task object. The task objects may be combined to form various business activity objects defined by a common task object, or index task object. Each task object can be further modified by combining a set of task characteristic objects with the base task object. The combinations of objects may be performed using associations created during operation of the CRM system.